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METHOD AND APPARATUS FOR ROUTING A SERVICE REQUEST 
IN A TELECOMMUNICATION SYSTEM 

FIELD OF THE INVENTION 

[0001] The present invention relates to a method and an 
5 apparatus for routing a service request in a 
telecommunication system towards a destination user 

BACKGROUND 

[0002] Users of telecommunication systems use to be 
assigned to one or more identifiers. Such identifiers are 
10 intended to be used by other users for requesting 
communications , and can take various formats according to 
the specific telecommunication technology for which they 
where devised. 

For example, E.164 numbers {ITU recommendation E.164, May 
15 1997) (commonly known as "telephone numbers") are usually 
used as identifiers in legacy telecommunication systems 
such as: PSTN (Public Switched Telephone Network), ISDN 
(Integrated Services Digital Network), or 2G (second 
generation) mobile systems. E.164 numbers where primarily 
20 defined for allowing routing telephony calls based on its 
numeric structure. So, for example, an E.164 number such as 
"+34 91 555 XXXX" could identify a user in Spain within the 
local area of Madrid. 

[0003] Identifiers used in modern telecommunication 
25 systems providing, for example, multimedia services (such 
as: video conference, data transfer, multimedia messaging, 
etc., as well as traditional voice-only calls) use to align 
with URI (Uniform Resource Identifier) format. Usually, 
these modern systems support also legacy identifiers, such 
30 as E.164 numbers, for interworking purposes with legacy 
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systems, as well as for keeping associated to the same user 
an old (legacy) identifier. DRIs are well-known identifiers 
widely used by Internet application and services for 
identifying resources (either: abstract of physical 
5 entities) . URIs are further divided as "locators" (Uniform 
Resource Locators, URLs) or "names" (Uniform Resource 
Names, URNs) . As opposed to URNs, that are intended to 
merely name a resource (even when the resource itself 
ceases or becomes unavailable), URLs identifies a resource 
10 by its location in a network (i.e.: identifies and locates 
it) . For the sake of a greater simplicity, and given that 
the abstract conceptual differences between URIs and URLs 
are tiny enough for considering them equivalent when 
referring string of characters that "identify" resources, 
15 the term URL shall be used hereinafter. 

Nowadays, URLs are assigned as identifiers to a plurality 
of heterogeneous resources for which service requests can 
be received. For example, an URL can be used to identify a 
web page, an electronic mail account, a file downloadable 
20 file, etc.. Identifiers associated to users that are served 
for a given service in a specific network domain, use to be 
URLs that has a format that comprises: a user-name portion 
and a domain-portion, separated by the separator character 
n @" . The domain-portion identifies the network domain 
* 25 serving a given user, who is named (and identified) as 

specified in the content of the user-name portion in said 
M : domain. 

: [0004} Telecommunication systems using a multimedia 

V : protocols, such as H.323 protocol (ITU-T recommendation 

:.: t 30 H.323, November 2000) or SIP protocol (IETF RFC2543 
"Session Initiation Protocol", March 1999), use URLs to 
identify their users (among other type of identifiers) . So, 
a user having a subscription with a telecommunications 
operator that owns a telecommunication system supporting a 
: 35 multimedia protocol such as SIP, uses to be assigned to an 
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identifier having an URL format (known as SIP-URL) that 
identifies said user in the network domain of said 
operator; for example w sip : John. Doe@CperatorA. se n . 
Similarly, for other communication services, such as 
5 traditional telephony, fax, electronic mail, modem based 
data calls, etc., a plurality of URLs can be defined to 
reach the destination user in the corresponding service 
point according to the requested service (e.g.: a plain 
n ' telephone, the inbox of a mail account, a fax machine, or a 

10 modem); for example: "tel:+98-7-6543210", 

"mailto : John . Doe@Opera torA. se" , n fax : -f 98-7-654321 0" , 
"modem : + 98-7-654321 0; type=vl 1 0" . 

[0005] A given user having a subscription with a 
telecommunications operator can, depending on the 
15 capabilities of the telecommunication system of said 
operator, an also depending on his/her subscription 
characteristics, receive a plurality of telecommunication 
services, or just only one type of services, having 
subscribed other services with another operator. 
20 For example, a user can have a subscription with Operator-A 
for basic telephony service, multimedia communication 
service and electronic mail service. Also, a user can have, 
for example, basic telephony and multimedia services 
fl subscribed with Operator-A, while keeping a subscription 

25 with Operator-B for solely multimedia service. 
„ An example of a telecommunication system able to provide a 

variety of telecommunication services and handle various 
: kind of identifiers for users (including E.164 identifiers 

V and URLs) is a 36 (third generation) mobile system having 

:.: : 30 the, so called, IMS (Internet Protocol Multimedia 
Subsystem) for providing multimedia services. 

[0006] E.164 identifiers have been widely used for 
identifying users of telecommunication systems providing 
}»\ telephony services; and, as mentioned above, many systems 
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still use E.164 identifiers as the only type of identifier 
that a user (originating user) can use for requesting a 
communication service towards another user {destination 
user) . The appearance of new telecommunication services 

5 made traditional telephony operators to offer some of these 
new services to their users. Among reasons such as: to 
allow an smooth migration towards a new telecommunication 
service replacing an equivalent old one (e.g.: a multimedia 
service in replacement of a traditional voice-only 

10 telephony service) , and to avoid user's inconvenience of 
publishing his/her new identifier (s) for the new service (s) 
subscribed; a given user subscribes a new service with 
his/her operator, uses to keep his/her old E.164 identifier 
associated also to this new subscription. So, for example, 

15 a given operator owning a 2G system and a 3G system with 
IMS, allows users subscribed to its 2G system to migrate 
their subscription to its 3G system while keeping their old 
E.164 identifiers. This allow these users to receive 
services from other legacy telecommunication systems, such 

20 as for example, calls or SMS (Short Messages) that are 
originally addressed using E.164 identifiers. 

[0007] When routing a service request to its destination 
user that contains an E.164 as identifier for said user, 
for some telecommunication systems (or for some parts of 
25 said system through which a certain protocol is used for 
signaling the service) said E.164 identifier can be found 
as not suitable for routing and/or identification purposes. 
: Also, in a given point of the execution of a service 

request, it can be desirable to select a service point 
::: 30 (e.g.: a given terminal of the destination user) where to 
finally deliver the service, being said user identified in 
said terminal with an identifier which is not the same as 

. . . 

the one received in the service request. 
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PRIOR ART SOLUTIONS 

[0008] The aforementioned scenario drove to devise 
solutions for obtaining the collection of identifiers 
related to a given identifier assigned to a user; and, more 
5 precisely (given the wide use made of E.164 identifiers)/ 
to obtain the collection of identifiers related to a E.164 
identifier. 

[0009] For example, IETF 1 s RFC2916 ("E.164 number and 
DNS", September 2000) (wherein the term DNS stands for 

10 "Domain Name System") discloses a DNS-based service to 
obtain information related to the various identifiers and 
service types related to a given E.164 identifier- The 
service provides the plurality of URLs related to a given 
E.164 identifier, and can be used, for example, when a 

15 service request comprising an E.164 identifier is received 
(e.g.: a telephony call, a SMS, a multimedia session, 
etc. ) . 

[00010] Hereinafter, the term "ENUM-DNS" will be used 
across the present invention to refer to the translation 

20 method and translation system (query translation 
mechanisms, DNS database structure, specific data 
structures for supporting translation of E.165 identifiers 
to ORLs, etc.) disclosed in RFC2916 and summarized below 
(the same term is also utilized in another standard 

25 specification that will be further cited across the 
detailed description) . 

[00011] According to RFC2916, a plurality of identifiers 
are stored in a data base. Said data base is structured and 
accessed (queried) using the well-known DNS technology. 
30 For this purpose the received E.164 identifier is arranged 

(as described below) to query a DNS-based data base in a 



similar manner as other DNS-based queries are done. Since 
the domain "el64.arpa" is being populated to provide the 
infrastructure in DNS systems for storage of E.164 numbers , 
said domain identifier is included in the query. 
5 For example, for a received E.164 identifier such as: 
9876543210 

the next query is should be made to a DNS: 
0.1.2.3.4.5. 6.7.8.9.el64.azpa 

wherein the received digits in the E.164 identifier have 
10 been inverted to fulfil existing DNS structured analysis 

(structured hierarchically from right to left) . 

As a result a plurality of ORLs that are stored in the DNS 

in relationship with said E.164 identifier are received as 

a result of said query. Each of these URLs can be related 
15 to a specific service, although more than one can be 

related to the same service. For example, the query can 

yield a set of identifiers such as: 

sip: John.Doe@CperatorA.SB (a SIP-URL) 

telz+98-7-6543210 (a TEL-URL) 

20 fax:+98-7-6543210 (a FAX-URL) 

mailto:aoJin.DoegqperatorA.se (a MAILTO-URL) 

sLpiJohnnyDoe@OperatorB.fr (a SIP-URL) 

that are stored in DNS as NAPTR RRs (Naming Authority 

Pointer DNS Resource Records) , and that can be used as 

25 valid routable identifiers for further routing the service 

request that contained the E.164 identifier. 

[00012] Among said identifiers, the querying entity {for 
example, a node in the telecommunication service) can 
select one of them and further route the service request 

30 according to it. For example, the most appropriate URL for 
delivering the requested service can be selected according 
to the requested capabilities; so for example, if the 
service requested is a voice call, then any SIP-URL can be 
selected for delivering it into a SIP-enabled terminal of 

35 the referenced destination user. Alternatively, the second 
URL {tel:+98-7-6543210) could be selected if it is desired 
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to deliver the call, for example, to a plain telephone set 
through a legacy telephony system* 

The further routing of the service, would depend on the 
nature of the selected URL. So, for example, if the 

5 selected URL has a user-name portion and a domain-name 
portion, then the service is routed primarily to the domain 
specified by the domain-name portion. For example, if the 
selected URL is the first one, then the service is routed 
towards the network domain of "CperatorA" in Sweden* If, 

10 however, the fifth URL is selected, then the service should 
be routed towards the network domain of "OperatorB" in 
France . 

[00013] However, the above referenced RFC2916 does not 
discloses what to do when more than one identifier is 
15 received related to the same service type for a ENUM-DNS 
query translation mechanism (for example, when more than 
one SIP-URL are received as a response to a query made with 
an E.164 identifier), and even having the same "order" and 
"preference' 1 fields. 

20 [00014] Avoiding this non desirable situations by means of 
defining a single URL per service related to an E.164 
identifier could be not feasible. In fact, the identifiers 
to be stored within NAPTR RRs in DNS related to E.164 
identifiers can be (as for other similar issues dealing 

25 with identifiers of telecommunication users, such as Number 
Portability) a national regulatory matter that can differ 
from country to country. So, for example, in some 
situations the content of said resource records will depend 
to a great extent on what the user assigned to the E.164 

30 identifier decides; while in other situations, the final 
content shall be determined by the operator that 
(originally) owns the subscription said E.164 identifier 
belongs to (i.e.: the "home operator" for said identifier). 
Then, this would drive to situations in which there can be 
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more than one URL per service related to a given E.164 
identifier stored in ENUM-DNS. 

On the other hand, while keeping the global addressing 
possibilities of the E.164 identifier largely used by 
5 (assigned to) a given user, it should not be desirable to 
limit the number of subscriptions said user can have to a 
given (new) service (such as a multimedia service based on 
SIP) with more than one telecommunications operator. 
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SUMMARY OF THE INVENTION 

[00015] The present invention provides a method/ an 
apparatus and a system for routing a service request in a 
telecommunication system when a plurality of routable 
5 identifiers, related to an identifier received in the 
service request , are obtained for routing said service. 

[00016] According one aspect of the present invention, it 
is provided a method for routing a service request that 
contains a specific identifier associated to the user who 

10 is the destination of said service. The method comprises a 
first step in which a plurality of identifiers are stored 
in relationship with said specific identifier; any of said 
plurality of identifiers being suitable for routing further 
service requests that can be received for said destination 

15 user and that comprise said specific identifier, wherein, 
at least one identifier of said plurality of identifiers 
has a format that comprises a user-name portion and a 
domain-name portion, being said specific identifier 
contained within the user-name portion. In a further step, 

20 when a service request comprising said specific identifier 
is received, all or a part of said plurality of identifiers 
related to the received specific identifier are obtained; 
then, if one identifier among said plurality of identifiers 
has a format as described above, and its user-name portion 

25 contains the received specific identifier, it is selected 
for further routing the service. 

[00017] According to a further aspect of the invention, it 
is provided an apparatus for routing a service request in a 
telecommunication system. The apparatus comprises: 
30 communication means, arranged for receiving a service 
request that contains a specific identifier assigned to the 
user who is the destination of said service; processing 
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means , arranged for obtaining the plurality of identifiers 
related to the received specific identifier that are 
suitable for routing a service requests that contains said 
specific identifier, and are further arranged for selecting 

5 an identifier among said plurality of identifiers that has 
a format that comprises a user-name portion and a domain- 
name portion, wherein the user-name portion contains the 
identifier received in the service request; and routing 
means arranged to further route the received service 

10 request according to the selected identifier • 

[00018] According to a further aspect of the invention, it 
is provided a system for routing a service request in a 
telecommunication system. The system comprises: a data base 
and a serving node in said telecommunications network which 

15 is in charge of receiving a service request towards a 
destination user, and further routing said service request. 
The data base stores a plurality of identifiers that are 
related to a specific identifier associated to a user, and 
it is arranged for answering a query that comprises the 

20 content of said specific identifier with all or part of 
said plurality of identifiers. The serving node is arranged 
to send a query to said data base when it receives a 
service request that contains said specific identifier, 
said query comprising the content of the identifier 

25 received in the service request. When the response to the 
query is received in the serving node, it is arranged to 
select one identifier, among the plurality of identifiers 
received in the query, that has a format comprising a user- 
name portion and a domain-name portion if the user-name 

30 portion contains the identifier received in the service 
request . 

[00019] In situations in which two or more identifiers are 
obtained for routing a service request, and specially when 
these identifiers are related to different service types 
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and/or different network domains; the aspects disclosed in 
this invention allows to identify a particular network 
domain that holds an identifier that contains the one 
received in the service request , and to route the service 
5 to it. This permits further decisions for delivering said 
service, such as, for example, change of service type, 
selection of the destination terminal, etc., to be taken in 
the identified network domain. 

BRIEF DESCRIPTION OF DRAWINGS 

10 [0010] Fig.l shows an schematic view of a two serving 
nodes of a telecommunication system and a signaling flow of 
a service request and its further routing according to the 
invention: 
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DETAILED DESCRIPTION 

[00020] The invention shall now be described in detail 
with reference to Fig.l according to a preferred 
embodiment. Said preferred embodiment considers a 3G mobile 

5 system that implements the so called IMS (Internet Protocol 
Multimedia Subsystem) and its standardized protocol for 
signaling services , as an example of a telecommunication 
system where the objects, features and advantages of this 
invention can apply. 

10 3G systems are standardized by the standardization forum 
3GPP (3 rd . Generation Partnership Project); being the well 
known protocol SIP (Sesision Initiation Protocol) the one 
chosen by 3GPP for signaling services within the IMS of a 
3G system. 

15 As mentioned previously, this kind of telecommunication 
systems (3G systems having the subsystem IMS) are able to 
provide variety of telecommunication services, such as 
voice calls through circuit-switched technology, voice or 
multimedia sessions through packet- switched technology, 

20 etc.; and handle various kind of identifiers for 
identifying users, including E.164 and URLs. So, when 
handling service requests, they can face the need of having 
to translate a given identifier, such as an E.164 telephone 
number, to a more suitable identifier, such as a SIP-URL, 

25 for further routing the service to its final destination. 

[000213 However, it shall be understood that the scope of 
the present invention is not limited to said 3G systems nor 
to a specific signaling protocol; and that a skilled person 
can readily apply it to any telecommunication system that 
30 receives a service request that contains a given identifier 
associated to the destination of said service, when said 
identifier is, either: not suitable, or not wanted for 
further routing the service, and , at least, one of a 



13 

plurality of routable identifiers related to said given 
identifier has to be used for said purpose. 

[00022] For the IMS subsystem of a 3G mobile system, the 
3GPP forum has defined a set of functional server entities 

5 in charge of various specialized functions. Among them 
there are the, so called, CSCFs (Call State Control 
Functions) which are in charge of serving control for 
services. A CSCF is a functional entity that performs a set 
of functions, such as: communication functions, to 

10 communicate with other entities; processing functions, for 
carrying out various service logic related to a service 
which is handled on it; and routing functions, for routing 
communications to other entities. 

Depending on implementation aspects (not standardized by 
15 3GPP, nor relevant for the understanding and scope of the 
present invention) , a CSCF can be located within a physical 
machine (i.e.: a physical telecommunication node), or 
distributed across a plurality of physical machines that 
co-operate for performing its functions. 
20 As a summary, it can be assumed that a CSCF is a serving 
node in a telecommunication system, such as an exchange in 
a PSTN, or a MSC (Mobile Switching Centre) in a 2G mobile 
system, in charge of performing control functions for the 
services it serves (i.e.: receives, routes or processes). 

25 [00023] According to 3GPP terminology for IMS entities, a 
CSCF is further named as P-CSCF (Proxy-CSCF) , I-CSCF 
( Inter rogating-CSCF) or S-CSCF (Serving-CSCF) according to 
its role while handling a service request. So, a CSCF is 
named P-CSCF when communicating with an end user terminal, 

30 a I-CSCF when it is the first serving node within an 
operator's network that receives services requests for a 
destination user who is subscriber of said operator, and S- 
CSCF when it is in charge of serving control for a service 
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either: originated by a user, or terminating in a user, to 
whom it has been assigned to serve. 

[00024] Reference is now made to Fig.l to illustrate the 
features of the present invention in a state-of-the-art 3G 
5 telecommunication system having IMS, and arranged to query 
an ENUM-DNS data base to obtain identifiers related to a 
given E.164 identifier. 

In Fig.l two CSCFs are shown (S-CSCF, I-CSCF) , each one 
having its own name (cscf.OperatorX.fr, esc f \ OperatorA.se) , 

10 that intends to represent a CSCF in the network domain of a 
given operator ("OperatorX") in a given country (France) 
that acts as Serving-CSCF for the user (or entity) 
originating said service, and another one belonging to 
another operator ("Operator A") in another country (Sweden) 

15 that acts as Interrogating-CSCF for the destination of the 
service. However, both CSCFs depicted in Fig.l could belong 
to the same operator, being the case of distinct operators 
more appropriate to highlight the advantages of the 
invention. 

20 At this point, it shall be noticed that, according to 3GPP 
specifications for IMS, the CSCFs are referenced with their 
individual names; as it is shown, for example, in 3GPP 
specification 24.228 (version V5.0.0, March 2002) that 
shows detailed signaling flows for services in IMS. Since 

25 said individual names (URLs) have to be resolved into the 
corresponding individual addresses suitable for addressing 
messages according to the underlying network protocol 
(e.g.: an Internet Protocol address, or IP-address), by 
using, for instance DNS or similar technique) , they usually 

30 shall contain a domain portion identifying the network 
realm of the 3G system operator they belong to. 
Fig.l also shows an ENUM-DSN data base. It can comprise one 
data base, or a set of hierarchically related data bases. 
In any case, particular implementation details related to 

35 said database, even if it , is based on DNS technology or 
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not, are not relevant for the scope of the present 
invention; wherein, the only relevant aspects for its 
understanding are: that said data base is in charge of 
storing a collection of identifiers related to a given 
5 identifier; and that said data base is arranged for 
receiving a query that contains said given identifier, and 
to answer the query with one or more among said plurality 
of identifiers. 

[00025] Step 1 in Fig.l represents the reception of a 
10 service request in a CSCF (S-CSCF) . The service can be, for 
example, a session (i.e.: call, multimedia session) 
requested towards a destination user that can be located 
within the network domain of the operator where said CSCF 
belongs to, or located within the network domain of another 
15 operator. 

As cited above, services within the IMS of a 3G system are 
signalled by using SIP protocol. So, in this example case, 
a SIP message INVITE should be received by the 
communication means of said CSCF. 
20 The INVITE received in step 1 shall contain a valid 
identifier for the user who is destination of the service. 
According to SIP protocol, said identifier takes the form 
of a URL. So, from SIP protocol point of view, there would 
not be any problem for routing the received service request 
25 (INVITE) according to the URL indicated as destination. 
Said URL could be, for example, a TEL-URL (URL for 
telephony, as disclosed in RFC2806 " URLs for Telephone 
Calls", April 2000) or a SIP-URL (URL for SIP, as disclosed 
in the aforementioned RFC2543 " Session Initiation 
30 Protocol") . This would then not preclude to further route 
the received INVITE according to the received URL 
associated to the destination, and without modifying said 
URL. 

In some situations, it might be wanted, however, to change 
35 the destination of the INVITE. For example, the destination 
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user has registered into a SIP-based system from two 
terminals and has specified a certain delivery criteria for 
receiving services. In this case, for example, an 
specialized SIP-server can provide the appropriate 
5 identifiers in order to further route the INVITE to any (or 
both) of these two terminals. 

[00026] However, as specified for example in 3GPP 
specification 23.228 (version V5.3.0, January 2002) (as 
well as in older versions of the same specification) , non 

10 SIP-URLs (such as a TEL-URLs) shall not be used for routing 
services within the IMS of a 3G system, and would have to 
be converted into routable SIP-URLs using ENUM-DNS. 
So, for example, if the URL for the destination received in 
the INVITE of step 3 is a TEL-URL such as: 

15 tel ; +98-7-654321 0 

it would have to be translated, by using ENUM-DNS or any 
other suitable mechanism into a routable SIP-URL. 
For this purpose, a state-of-the-art serving node of a 
telecommunication system, such as the CSCF (S-CSCF) of the 

20 example case, would query in step 2 to an ENUM-DNS data 
base. The query would (as mentioned earlier in connection 
with the prior-art) comprise the received E.164 identifier 
arranged properly to query to a DNS-based data base. 
According to this, the query sent in step 3 would contain: 

25 0.1.2.3.4.5.6.7. 8. 9.&164 .arpa 

[00027] The queried data base can have a plurality of 
identifiers related to the identifier M 9876543210 ,f ; 
however, for the purpose of ENUM-DNS lookup, the only 
relevant to this kind of query (E.164 to URL) are the 
30 identifiers having URL format. Therefore, the ENUM-DSN data 
base would answer back with those URLs that are related in 
said data base to the E.164 identifier used in the query. 
Using the example case depicted in Fig. 2, in step 3 the 
CSCF (S-CSCF) would receive the next URLs: 



17 

sip : JohnnyDoeQOpera torB . fr 
mailto:John.Doe@QperatorA. se 
sip: 9876543210@CperatorA.se 
tel: +98-7-6543210 

5 [00028] In this example case, since multiple URLs are 
received, processing means in the CSCF (S-CSCF), unless 
forking method for multiple service delivery are 
implemented (which is costly and, sometimes, not 
effective) , would have to select in step 4 one these URLs 
10 and route the service according to it* If the TEL-URL 
(tel:+98-7-6543210) is selected, a telephony call should 
then be established by towards the E.164 identifier 
contained in said TEL-URL. If said E.164 identifier does 
not belongs to Opera torX's domain, then it can be, for 
15 example, routed to the PSTN through the signaling and media 
gateways that link the telecommunication system of 
OperatorX with a PSTN operator that would end up in the 
network domain of the operator that handles a telephony 
subscription addressed by said .164 identifier • 
20 Also, there could be the particular case in which all the 
received identifiers would belong to the same operator as 
the CSCF that received the INVITE (OperatorX). In this 
case, the CSCF (S-CSCF) can query with any of the 
identifiers to the home server entity (known as HSS or HLR) 
25 of said OperatorX that would, in turn, provide the address 
of the CSCF serving the corresponding user addressed by 
said identifiers. The service would be further routed with 
any of the received SIP-URLs to said CSCF that, in turn, 
could apply a further routing criteria according to, for 
30 instance, user preferences or user profile. So, in this 
latest case, it would be the CSCF serving to said user the 
one deciding where to route the service. 

[00029] However, if the identifiers received in step 3 
does not belong to the operator said CSCF (S-CSCF) belongs 
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to ( Opera torX) , user preference data and/or user profile 
data of a destination user that belong to another operator 
(e.g.: OperatorA or OperatorB) , and that would allow this 
CSCF (S-CSCF) to make a selection with a certain basis, are 

5 far away to be known (or accessed) by this CSCF of 
qperatorX. In fact, even the identifiers received in step 3 
would belong to the same operator said CSCF (S-CSCF) 
belongs to, IMS standardized procedures preclude in this 
situation to a CSCF acting as a originating S-CSCF to query 

10 to the HSS for this purpose; and also, as mentioned before, 
IMS standardized procedures preclude the further routing of 
the service with other identifier than a SIP-URL. 

[00030] Moreover, even in case that one or more SIP-URLs 
are received from the data base that pertains to the domain 

15 of OperatorX, if there is at least one SIP-URL among the 
ones received from the data base that pertains to another 
operator, it can be doubtful to take the decision of 
discarding that SIP-URL for further routing the service. 
For instance, two URL are received as a response to the 

20 query sent to the data base; one URL belongs to OperatorX, 
while the other to OperatorA. If the destination 
subscriber, to whom the E.164 is assigned, had originally, 
and still has, a basic (legacy) telephony subscription with 
OperatorA associated to said E.164 identifier (e.g: the 

25 number series of said E.164 identifier originally belonged 
to Operator A) ; and has now also a multimedia subscription 
with said OperatorA; then to route the service towards 
OperatorA can probably be the most appropriate decision; 
mainly if the E.164 identifier can be subject to Number 

30 Portability and queries for portability are made in the 
Number Range Holder Network. So, once the service would get 
OperatorA' s domain, user preferences and user profile 
related to the subscription of the destination user in said 
domain shall be further checked to determine the final 
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routing and delivery criteria for the service. However, 
these (possible) facts can also be far away to be known (or 
accessed) by this CSCF (S-CSCF) . 

[00031] To overcome the problems above, as a part of the 
5 administrative process of populate data through DNS system 
(such as done for populating data related to Number 
Portability), an operator that has, for example, a 
situation similar as the one described above for OperatorA, 
in which, it holds a basic (legacy) telephony subscription 
10 addressed with a legacy identifier (such as an E.164 
identifier) not suitable or not desirable for routing 
according to a new service type, and a hew subscription for 
a new service type (such as multimedia services via SIP), 
or the same subscription encompassing both services; should 
15 populate a URL to be stored in DNS-ENUM that allows 
identify uniquely said operator^ domain as the one 
primarily holding said legacy identifier (e.g.: an E.164 
identifier) . 

[00032] In cases where the new service type uses URL 
20 identifiers, this can be accomplished by defining an URL 
having, in the user-name portion the content of the legacy 
identifier, while in the domain-name portion contains the 
appropriate domain identifier, so as to form a routable 
FQDN (Full Qualified Domain Name) . Said URL, once stored, 
25 for example, in ENUM-DNS, together with the rest of 
identifiers related to the legacy identifier, would allow 
to distinguish it from the others and further route the 
service according to it. 

In the particular case of E.164 to URL translation; and, 
30 more precisely in case of E.164 to SIP-URL translation, the 
format of the URL to be populated shall contain the E.164 
identifier in a distinguishable format. For example, for an 
E.164 such as 9876543210 which is "owned" by operator 
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Operator A in Sweden, the SIP-URL could have a format such 
as : 

sip: 9876543210@OperatorA.se. 

Optionally, the user-name portion could contain additional 
5 information for various purposes, such as reinforcing the 
use of this URL, indicate identifier subject to Number 
Portability, etc. For the same case used as example, a 
readily distinguishable formats could also be: 

sip : 98 7654321 0 . El 64@Opera torA . se, 
10 sip:non ported_indication. 9876543210@QperatorA.se, 

sip:ported_indication. 9876543210. ported_identifier@OperatorC. it. 

[00033] According to the invention, processing means in 
the CSCF (S-CSCF) selects in step 4 a distinguishable URL as 
described above that contains the E.164 identifier used in 
15 the query of step 2, and further route the service 
according to said URL- This process, can imply a further 
query (not shown in Fig.l) to a translation service (such 
as DNS) to obtain name and/or network address of the 
corresponding CSCF where to send the INVITE in step 5. 

20 Additionally, if an indication of "non^ported" identifier 
was also received in the selected URL, a further query that 
could have been requested otherwise by this CSCF (S-CSCF) 
or by other serving node to obtain number portability 
information, can be avoided by considering said indication. 

25 Similarly, if an indication of " ported" identifier was 
also received in the selected URL, a further query that 
could have been requested otherwise by this CSCF (S-CSCF) 
or by other serving node to obtain number portability 
information, can be avoided by considering said indication 

30 together with the (new) ported identifier received that in 
this case, preferably, can contain the domain name of the 
(final) destination network handling the ported identifier. 

[00034] Upon reception in step 5 of the INVITE in the CSCF 
that first receives services requests for a destination 
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user (I-CSCF), I-CSCF of OperatorA in the example depicted 
in Fig.l, further state-of-the-art steps can take place. 
This implies, for example, query to the home server entity, 
HSS, of OperatorA that will provide the address of an CSCF, 
5 acting as S-CSCF, that is in charge of serving to the user 
who has assigned the identifier received in the INVITE 
(i.e.: the destination user). This CSCF can apply a further 
routing criteria which, for said destination user, are 
available to this CSCF in this destination domain of 
10 OperatorA. Said routing criteria can be based, for example, 
on user preferences, user profile, user location, etc.; and 
can involve, for example, a subsequent change of the 
received identifier and/or service type (e.g.: from SIP 
session to circuit-switched telephony call) , as it would 
15 happen if, for instance, the destination user has 
programmed a call forwarding towards another destination. 
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CLAIMS 

1. A method for routing a service request in a 

telecommunication system towards a destination user, the 
method comprising the steps of: 

a) storing a collection of identifiers related to a 
first identifier assigned to said user; 

b> receiving a service request that comprises said first 
identifier; 

c) obtaining a plurality of identifiers among said 
collection of identifiers; 

d) selecting a second identifier among said plurality of 
identifiers; and 

e) routing said service request according to said 
selected second identifier; 

the method characterized in that: 

at least one identifier among said plurality of 
identifiers stored in step a) has a format that 
comprises a user-name portion and a domain-name portion, 
wherein the user-name portion contains said first 
identifier; and 

in step d) said second identifier is selected having a 
format comprising a user-name portion and a domain-name 
portion, wherein said user-name portion contains said 
first identifier, 

2. The method of claim 1, wherein the step c) further 
comprises the steps of: 

cl) sending a query to a database that contains said 
collection of identifiers related to said first 
identifier, said query comprising the content of the 
first identifier; 

c2) receiving a response to said query that comprises a 
plurality of identifiers among said collection of 
identifiers. 

3. The method of claims 1 or 2, wherein said first 
identifier is a E.164 number and said second identifier 
is a Uniform Resource Locator for Session Initiation 
Protocol. 
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4. The method of claim 3, wherein said second identifier 
contains number portability information. 



5. An apparatus for routing a service request in a 
telecommunication system, the apparatus comprising: 

communication means arranged for receiving a service 
request towards a destination user, said service request 
comprising a first identifier assigned to said 
destination user; 

processing means arranged for obtaining a plurality of 
identifiers related to said first identifier and for 
selecting a second identifier among said plurality of 
identifiers; and 

routing means arranged to route said service request 
according to said selected second identifier; 

the apparatus characterized in that: 

said processing means are arranged to select a second 
identifier among said plurality of identifiers having a 
format that comprises a user-name portion and a domain- 
name portion, wherein said user-name portion contains 
said first identifier. 



6- A system for routing a service request in a 

telecommunication system, the system comprising: 

a data base, in charge of storing a collection of 
identifiers related to a first identifier associated to 
a user; and 

a serving node of said telecommunication system in 
charge of receiving a service request towards a 
destination user and further routing said service 
request; 

said data base being arranged to receive a query 
comprising the content of said first identifier, and to 
answer said query with a plurality of identifiers among 
said collection of identifiers; 

said serving node being arranged for querying said data 
base upon reception of a service request that comprises 
said first identifier, and further routing said service 
request according to an identifier selected among said 
plurality of identifiers; 

the system characterized in that: 
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said serving node is further arranged for routing 
service request according to an identifier selected 
among said plurality of identifiers that has a format 
comprising a user-name portion and a domain-name 
5 portion, wherein said user-name portion contains said 
first identifier. 

7. The system of claim 6, wherein said first identifier is 
a E.164 number and said second identifier is a Uniform 
Resource Locator for Session Initiation Protocol. 

10 8. The system of claim 7 , wherein said wherein said second 
identifier contains number portability information. 




m 



25 



ABSTRACT OF THE INVENTION 

A method for routing a service request in a 
telecommunication system in cases where the identifier 
received for the destination of the service is not (or can 

5 not be) suitable for routing the service , such as when a 
£•164 number is received in IP based multimedia 
telecommunication systems. Upon reception of a service 
request in a telecommunications node of the 
telecommunication system in charge of serving control for 

10 services, a query comprising the received identifier is 

made to a translation database. As a result, a plurality of 
identifiers related to the received identifier are received 
that can have different formats and imply different service 
types. The service is further routed from said 

15 telecommunications node according to an identifier selected 
among said plurality of identifiers that contains the 
primarily received identifier in the user name portion. 
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